Automated auctions, including on-line auctions such as those provided through the Internet, are becoming an increasingly popular tool by which individuals, companies or organizations can obtain the lowest possible prices for goods and services that they purchase or obtain the highest possible price for goods and services that they provide. In general, auctions may come in one of two broad types. A standard auction is one in which bidders wishing to purchase goods or services selectively increase their bids in an effort to earn the right to purchase particular goods or services by submitting the highest bid. In a reverse auction, bidders wishing to provide goods or services selectively decrease their bids in an effort to earn the right to provide particular goods or services by submitting the lowest bid.
Conventionally, an automated auction is administered by an individual auction server. The auction server may be connected to a computer network such as the Internet and run auctioning software on behalf of the individual, company or organization administering the auction. Individual bidders may access the auction server via the computer network using a so-called “thin client,” which is typically a Web browser displayed via a desktop or laptop computer at the home or office. The individual bidder identifies goods or services that he or she wishes to bid on, manually enters a bid via the Web browser, sees bids from competing bidders, and then selectively changes the bid until the auction is completed, at which point the bidder learns whether he or she has been successful.
An example of a conventional automated auction is illustrated in FIG. 1. Briefly, a number of individual bidders access one or more of a plurality of auction servers 10, 11 and 12 belonging to different auctioneers via Web browsers running on desktop computers 14-24. While a specific number of components is shown in FIG. 1, the total number of auction servers/auctioneers and bidders is arbitrary. Further, the actual interconnection between individual computers and the auction servers may be provided via the Internet or via another suitable networked communication system, not separately shown. In some cases, individual bidders access only a single auction server. In other cases, individual bidders access multiple auction servers concurrently. Even when accessing only a single auction server, an individual bidder may simultaneously bid on multiple items. When bidding on multiple items in a single auction, typically, only a single Web browser interface with that auction server is required. However, when bidding on items offered in different auctions administered by different auction servers, multiple Web browsers are required. This conventional scenario is generally sufficient so long as individual bidders are acting on their own.
With conventional systems, such as that illustrated in FIG. 1, significant problems may arise when the bidder is a company or organization which established and authorized a group of employees, contractors or other individuals to make bid decisions and submit bids. Typically, the members of such a bidding group need to collaborate with one another in determining bid prices. For example, in order to determine the optimal bid price for offering a large number of consumer products in a reverse auction, the bidder may need to know the current prices of raw materials used to make the consumer products, the current costs of any items provided by sub-suppliers, the current production capacities of various manufacturing plants around the world, and the like. This information may need to be obtained from a variety of co-workers throughout the company. Determining an optimal bid price might also require a procedural and approval work-flow within the company, all resulting in a considerable collaboration effort. Given relatively small profit margins, particularly within consumer products, it is critical to identify optimal bidding prices and to do so in a timely manner.
In the example of FIG. 1, users 14-16 represent one collaborative group 26 or “collaborative bidding entity,” whereas users 18-22 represent another collaborative group 28 or collaborative bidding entity. The different collaborative groups may, for example, represent competing companies. Collaboration, even between co-workers of a single company or organization, can be particularly difficult if the collaborators work in different parts of the world, speak different languages, use different currencies, or the like. See, for example, FIG. 2, which illustrates an example wherein the users of a collaborative group are working at widely separated locations around the world. Given the differences in time zones, languages, etc., it can be quite difficult for individuals who need to collaborate on an individual bid to properly collaborate in a timely manner. In some cases, by the time the individuals have reached some decision as to an initial bid and have obtained the authorization from their superiors to submit that bid, the auction may well be over. In order to submit a bid in a timely manner, an individual may have to proceed without all the appropriate information, thus resulting in a non-optimal bid price. In other cases, an individual employee may have the authorization to submit bids within a particular auction, but that bid needs to be coordinated with other bids submitted to other auctions concurrently so as to prevent unnecessary duplication of purchases. In some cases, the business may have a maximum budget allocated for purchasing goods or services the auctions, such that bid submitted to different options must be in coordinated to prevent exceeding the total budget. As can be appreciated, these problems become more and more significant if more and more parties become involved in any given collaborative bidding effort.
Another problem with the conventional bidding solutions is that managing and submitting individual bids, even without the need for collaboration, can be quite labor-intensive. In the context of a company or organization that purchases a large number of goods or services through auctions (or which provides a large number of goods or services via reverse auctions), quite a few individuals may need to be employed to track down goods or services to be purchased at auction, to determine appropriate bidding prices, and then to submit and monitor those bids. Moreover, during the final “hot phase” of an auction, individuals are sometimes not able to make decisions fast enough in order to win the auction. Also, there is a considerable opportunity for bidding errors. Furthermore, when bidding on auctions via a “thin client” there is little or no independent recordkeeping of the auction on the bidder side. It is up to the individual to record bid prices, transactions, etc. Without effective recordkeeping, compliance with tax codes and other legal obligations and compliances can be problematic. Moreover, it can be difficult to adjust bidding strategies for upcoming auctions based upon the success or failure of bidding strategies used in prior auctions without adequate records of those prior auctions.
Hence, there is a significant need to provide improved bidding methods, systems and techniques, particularly for use in collaborative bidding arrangements, and it is to that end that aspects of the invention are directed.
Yet another problem with the conventional auctioning methods and systems is that significant computing power hardware demands are placed upon the auctioning servers, particularly if a large number of different items are being auctioned. Also, one item might be bid on by a large number of bidders. However, the high demand of hardware for auctioning servers results not only from the large bidder numbers but more so from the need to provide each bidder with information of all other bidders actions. These demands are also present in more general “collaborative communications” scenarios. In this context, collaborative communications refer to scenarios where a plurality of clients “collaboratively” work on a common case by transmitting data from each individual client to all other clients, sharing data there-between and exchanging data among each other. Each communications activity accomplished by a client can have impact on parallel and subsequent communications activities of other clients.
In collaborative communications, resources of a central auctioning server can be considered being determined by three terms adding up to total consumption. First, resources of a central server depend on the number of transactions, for instance electronic auctions, performed during a certain period of time. This first term represents the effort of a transaction excluding client communication processing. For the auction example, this would be the processing for setting up an action and operating it.
For this term, it is assumed that the communications activity of one client can be executed asynchronously and independently from communications activities of all other clients and that no access to shared data is required. The resource percentage of the central server required for execution of one communications activity can be considered as a constant. This term linearly increases with the number of transactions performed during a certain period of time like a month or a year and can be defined by:CSR1=R*N,  Eq. 1wherein                CSR1 indicates the overall Central Server Resources (CSR),        R indicates a resource factor of the central server for carrying out one transaction excluding client communication processing, and        N indicates the number of transactions during the certain time period.        
Resources of the central server further depend from a second term concerning the fact that many clients participate in a collaborative communications scenario. This term is proportional to the number of clients and their communications activities for participating in a transaction excluding the efforts of exchanging data among all clients. For instance, in the auction example this would be the processing a bidder does for retrieving basic information about the subject of the auction like a request for quotation or an item description. This term normalized to the certain time period like above can be defined by:CSR2=n*CCR*N,  Eq. 2wherein                CSR2 indicates overall resources of a central server,        n indicates the number of participating clients,        CCR indicates a factor for Collaborative Communication Resources (CCR) for one client communication activity during a certain time period, and        N indicates the number of transactions during the certain time period.        
Finally, a third resource term considers that all clients participating in a collaborative communications scenario are provided information concerning each other's communications activities. In the auction example, this would be for instance the effort of distributing one bidder's bid as a new best bid to all other bidders. According to the third term, resources of the central server increase with a square of the number of client. This term can be defined by:CSR3=n2*CIR*N,  Eq. 3wherein                CSR3 indicates overall resources of a central server,        n indicates the number of clients participating in a collaborative communications scenario,        CIR indicates a factor for Communicating Information Resources (CIR) concerning collaborative communications activities of clients among the participating clients, and        N indicates the number of collaborative transactions during the certain time period.        
In total, resources required for collaborative communications on the side of a central server can be defined by:CSR=CSR1+CSR2+CSR3=R*N+n*CCR*N+n2*CIR*N,  Eq. 4wherein CSR indicates overall resources of a central server to support collaborative communication.
As is apparent from Equation 4, methods and systems for collaborative communication relying on a central server supporting a very high number of clients are not be feasible as hardware requirements on the central server side are proportional to the square of the number of served clients. In other words, doubling the number of clients requires a four-fold increase in hardware resources for the central server if n is large and CSR3 becomes the dominant term. Hence, conventional automated auction systems or other collaborative systems that rely on a central server become economically unfeasible as the number of users or clients increases. Furthermore, even with smaller client numbers costs of such a central system are single sided only occurring on the central server provider side while benefits of collaborative business transaction are gained by all transaction participants: the provider and the clients.
Hence, there is a need to provide alternative systems, methods and techniques that more fairly distribute resource burdens and their costs. The alternative systems and methods should also better support and automate activities a client might have to do before communicating via a central server to the overall client community. It is to this end that further aspects of the invention are directed.